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(57) Abstract 

This software tool 
accessing methodology 
defines a powerful approach 
to interacting with smart 
card readers and smart cards. 
This software tool embodies 
the central software engine 
(Interface component), 
a series of configuration 
files, and modular plug-ins 
that provide methods 
for formatting cards and 
compatibility with evolving 
standards. This software tool 
enables effective building 
of smart card solutions 
without concern for the 
tedious detail of smart card 
vendor specifications and the 
unique interface challenges 
that exist widi smart card 
readers. Instead of having to 
hardcode instructions within 
a smart card application, card 
and reader information is 
accessed by the interface 
component using the data 
stored in configuration files 
to therefore create flexibility 
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and growth potential. The configuration files include information that tells how a software engine can communicate with an information 
system, a reader, and a card. This software tool is a mm-key solution when compared to existing very rudimentary smart card application 
development tools that require considerable smart card expertise and arc limited to a single card or reader type. 
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METHOD AND APPARATUS FOR FORMATTING 
SMART CARDS AND CARD READERS 

Field of the Invention 

The present invention relates to a card methodology 
and architecture for configuring a software engine used 
for creating new smart card applications within a 
programming environment, and more specifically relates 
5 to a software tool and methodology that provides 
flexibility in formatting and interfacing smart cards, 
card readers and information systems in an object- 
oriented application development environment. 
Background of the Invention 

10 In the past, many different smart card readers 

existed and many different smart cards were available. 
However, while some similarities existed among the 
various card readers and smart cards, every vender had 
unique features and capabilities that differentiated 

15 their products. This presented a steep learning curve 
for application developers who had to learn the 
intricate details regarding how a particular card and 
card reader functioned. In addition, once an 

application had been designed, transition across 

20 hardware products was very difficult without significant 
code rewrites. The software tools provided by hardware 
vendors were either weak or non-existent and thus 
created the following problems. 

For every different reader or card, there existed 

25 a unique set of commands. Example commands included: 
create file, create directory, present secret code, load 



secret code, reset reader, eject card, etc. Each 
command had an associated hexadecimal instruction. 
Addition or variation of commands or instructions 
created big problems since the instructions were 
hardcoded within the software engine. For example, a 
card could have the following commands: create file, 
write file, present code, and load code. However, if a 
new command were to be added such as "update code", the 
entire software engine would have had to have been 
rewritten. This would have been cumbersome, 

inconvenient, and time-consuming. 

With regard to readers, readers also differed in 
the way that they communicated with the cards, drew 
power (battery, host, external) , processed commands, and 
reported status and errors, for example- With regard to 
the cards, the cards were also very diverse (magnetic 
stripe cards, memory chip cards such as simple flash 
memory cards, card operating systems known as COS chip 
cards with programmable operating systems, and others) . 
Even within the COS family of cards, there were 
different support elements for directory structures, 
file allocation and access, encryption, secret codes, 
status and error messages, etc. 

In a system utilizing different smart cards and 
smart card readers, such a system was quite cumbersome, 
mostly because of the specialized smart card software 
that was provided by the hardware manufactures. Many of 
the tools for creating specialized smart cards to comply 
with a user's desired specifications were not high-level 
tools and were not easy to use. The tools did not 
create any common way to work with different smart cards 
and readers, and there was no existing development tool 
that permitted development of an application for 
different readers and cards. 
Summary of the Invention 

A first object of the present application is to 
overcome the aforementioned drawbacks and to create a 
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smart cai^d software tool useable in an interfacing 
architecture that allows a user to similarly interface 
with smart cards and/or card readers despite the source 
and compatibility standard of each card or reader. 
5 Another object of the present application is to 

provide ai self -configuring software engine usable for 
communicating with cards and card readers having 
different: formats and for creating and using files, 
directories or secret codes, for example. 

10 A still further object of the present application 

is to provide a tool for modifying smart card or card 
reader coihmands without the need to re-write an entire 
software engine. 

An even further object of the present application 

15 is to create a tool which provides flexibility by 
allowing the reformatting of a smart card and/or card 
reader with new information. 

These and other objects of the present application 
are fulfilled by providing a method for communicating 

20 with a card and a card reader, comprising the steps of: 
prestoring a plurality of files for configuring a 
software tool for communicating with the card as card 
conf iguratjion files; prestoring a plurality of files for 
configuririg a software tool for communicating with the 

25 card reader as reader configuration files; selecting a 
card configuration file ; selecting a reader 
configuration file; storing the selected card 
configuration file and reader configuration file; and 
configuririg the software tool for communicating with the 

30 card and card reader based upon the respective stored 
selected card and card reader configuration files. 

These and other objects of the present application 

i 

are further fulfilled by providing a method for 
communicating with a card, comprising the steps of: 
3 5 prestoring^ a plurality of files for configuring a 
software tool for communicating with a card; selecting 
one of the' prestored files; storing the selected file; 
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and configuring the software tool for communicating 
with the card based upon the stored selected file. 

These and other objects of the present application 
are still further fulfilled by providing a method for 
communicating with a card reader, comprising the steps 
of: prestoring a plurality of files for configuring a 
software tool for communicating with a card reader; 
selecting one of the prestored files; storing the 
selected file; and configuring the software tool for 
communicating with the card reader based upon the stored 
selected file. 

These and other objects of the present application 
are even further fulfilled by providing an apparatus for 
formatting a card, comprising: a first memory for 
prestoring a plurality of card configuration files for 
configuring a software tool for formatting the card; a 
selection function for selecting one of the prestored 
card configuration files based upon card type; a dynamic 
memory for storing the card configuration file selected 
based upon card type, wherein the software tool is 
configured based upon the stored card configuration 
file, the selection function further selects at least 
one command for formatting the card, and the selected at 
least one command is stored in memory on the card; and 
processing function for formatting the card based upon 
the at least one selected stored command. 

These and other objects of the present application 
are still yet further fulfilled by providing an 
apparatus for formatting a card reader, comprising: a 
first memory for prestoring a plurality of card reader 
configuration files for configuring a software tool for 
formatting the card reader; a selection function for 
selecting one of the prestored card reader configuration 
files based upon card reader type; a dynamic memory for 
storing the card reader configuration file selected 
based upon card reader type, wherein the software tool 
is configured based upon the stored card configuration 
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file, the selection function further selects at least 
one cominand for formatting the card reader, and the 
selected at least one command is stored in memory of the 
card reader; and a processing function for formatting 

• 5 the card reader based upon the at least one selected and 
stored coinmand. 

These and other objects of the present application 
are still even further fulfilled by providing an 
apparatus for formatting a card and a card reader, 
10 comprising: a first memory for prestoring a plurality of 
card configuration files and a plurality of card reader 
configuration files for configuring a software tool for 
formatting a card and card reader; a selection function 
for selecting one of the prestored card configuration 

15 files and one of the card reader configuration files 
based upon respective card and card reader type; a 
dynamic memory for storing the card and card reader 
configuration files selected based upon the respective 
card and card reader type, wherein the software tool is 

20 configured based upon at least one of the stored card 
and card reader configuration files, the selection 
function further selects at least one command for 
formatting at least one of the card and card reader, and 
the selected at least one command for formatting at 

25 least one of the card and card reader are stored in 
memory of the respective card and card reader; and a 
processing function for formatting at least one of the 
card and card reader based on the respective selected 
and stored command • 

30 These and other objects of the present application 

will become more readily apparent from the detailed 
description given hereinafter. However, it should be 
understood that the detailed description and specific 
examples, while indicating preferred embodiments of the 

35 invention, are given by way of illustration only, since 
various changes and modifications within the spirit and 
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scope of the invention will become apparent to those 
skilled in the art from this detailed description. 
Brief Description of the Drawings 

The present invention will become more fully 
5 understood from the detailed description given 
hereinbelow and the accompanying drawings which are 
given by way of illustration only and thus are not 
limitative of the present invention, wherein like 
elements are represented by like reference numerals 
10 throughout, and wherein: 

Fig. 1 illustrates an overall block diagram of the 
software tool, the smart cards and the card reader; 

Fig. 2 illustrates the components of the card 
reader ; 

15 Fig. 3 illustrates the components of the smart 

card ; 

Fig. 4 illustrates the components of the tool for 
formatting the smart card and card reader; 

Fig. 5 illustrates a flowchart of the setup phase 
20 for configuring the software tool, prior to formatting 
the smart card and card reader; 

Fig. 6a-6c illustrate the operational phase for 
constructing various commands to format the smart card 
and card reader; and 
25 Fig. 7 illustrates an interfacing architecture and 

accessing methodology that incorporates the software 
tool in accordance with an embodiment of the present 
application. 

Detailed Description of Preferred Embodiments 
30 The disclosed software tool and methodology enable 

interacting with smart cards and smart card readers. 
The tool and methodology can be used in well-defined 
interfacing architectures that are compatible with 
current and developing standards, and also accommodating 
35 to non-standard products. 

Fig. 1 illustrates the main components of the 
present application for configuring a software tool. 
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usable for formatting or otherwise communicating with 
advanced card systems such as smart cards and/or card 
readers to meet user specification. A software tool 3 00 
allows the user to work with a smart card 200 via a card 
5 reader 100 as shown in Fig. 1 for example^ and create 
files, directories, and secret codes to meet a user 
specification. Basically, the software tool 300 allows 
the user to create desired smart card software 
independent of the type of card reader 100 and the smart 

10 card 2 00. In addition, the software tool 300 allows a 
user to similarly create card reader software for a card 
reader 100 shown in Fig. 1 for example, independent of 
the type of smart card 200 and card reader 100- 
Further, the software tool 300 allows a user to reformat 

15 a smart card reader 100 and a smart card 200 with new 
inf oinmation. 

Fig. 2 illustrates components of a card reader 100 
for example. The card reader 100 can include a central 
processing unit (CPU) 110 and some type of memory 120. 
20 The memory 120 is represented as a single element in 
Fig. 2 for the sake of brevity, but of course can 
include an electrically erasable programmable read only 
memory portion (EEPROM) and a random access memory (RAM) 
portion. 

25 Many smart card readers 100 connect to the software 

tool 3 00 via a RS 232 serial port. The readers may be 
pass-through readers that simply passes communications 
between the software tool 300 and the card 200. The 
communication setting for the pass-through reader 100 

30 should be the same as the card 200 protocol. For 
example, a T = 0 transmission protocol card expects 8 
data bits, even parity and 2 stop bits. Other readers 
100 contain firmware that communicates with the software 
tool wins the reader protocol and translates the message 

35 to the card's protocol. Here, the software tool 300 
port is configured to match the reader's protocol. The 
preferred embodiment of this invention automatically 
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configures itself to match the desired protocol. That 
is, for a pass-through reader, the software tool 300 is 
configured to match the expected card protocol. 
However, for other port readers, the reader protocol is 
5 matched . 

Fig. 3 illustrates the basic components of the 
smart card 200. A smart card, for example, is a card 
with at least a CPU 210 and memory 22 0 as shown in 
Fig. 3. The memory 220 can include an EEPROM portion 
10 and a RAM portion similar to that of the card reader 100 
shown in Fig. 2 for example. If the card is a chip card 
that can store data but have little or no processing or 
internal file allocation capabilities, then data is 
addressed directly. If the card is based on an internal 

15 CPU 210, then processing functions may include directory 
and file support, multilevel security management and 
built-in cryptography for encrypting and decrypting 
secured data. Most cards currently produced have a CPU 
210, and are more sophisticated than cards that only 

20 store data. 

The card methodology of the present invention can 
be used for a vast array of cards and card readers. For 
example , the cards can include magnetic stripe cards , 
memory chip cards, COS chip cards with programmable 

25 operating systems, etc. Further, the card readers can 
include a variety of readers for reading such cards. 

Fig. 4 illustrates the components of the software 
tool 300, The software tool 300, in a preferred 
embodiment, is built upon a standard computer work 

30 station. The card methodology is preferably built 
around a Microsoft Windows library of routines that 
provide support for interfacing smart cards 200 and card 
readers 100, wherein the software tool can communicate 
with and can be used to format smart cards 200 and card 

35 readers 100, either singly or in combination. In one 
preferred embodiment, the Microsoft Window library of 
routines is in the form of a component for the Delphi 
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Programming Environment. The software tool 300 creates 
a unique methodology for formatting all types of smart 
cards 200 and card readers 100 to create interf aceable 
smart cards 2 00 and card readers 100 based upon user 
specification through the creation of a series of 
configuration files. 

The basic components of the software tool 3 00 
include those of a basic computer workstation. A 
central processing unit 310 is used to control various 
components including a display 340, a memory 320, an 
input device 350, and a dynamic memory 33 0. The memory 
32 0 stores a variety of configuration files including 
CDC (card) files and RDC (card reader) files for a 
plurality of card and card reader types. Based upon a 
particular type of smart card or card reader, a card or 
card reader configuration file is selected by input 
device 350 and stored in dynamic memory 33 0. The 
software engine of the software tool, being an open 
engine, is then configured based upon the selected 
configuration file to permit easy communication with the 
particular type of card or card reader. Then, based 
upon desired commands for formatting or otherwise 
communicating with a smart card 200 or a card reader 
100, various commands are selected through input device 
350, These selected commands are then formatted and can 
then be stored in memory 220 and/or 120 to thereby 
communicate or format a desired smart card 200 and/or 
card reader 100 based upon user specification. 

Configuration files, including both CDC and RDC 
files, can further be displayed to a user on a display 
340, as can a list for formatting or otherwise 
communicating with a card or card reader. It should be 
noted that the dynamic memory 33 0 is merely 
representative in Fig. 4 and can include both random 
access memory and read only memory, as can memory 320 of 
Fig. 4. Basically, the memory 320 designates a memory 
for prestoring a plurality of files for configuring the 
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"open" engine of the software tool for use with various 
types of card readers and smart cards, and dynamic 
memory 33 0 designates a memory for storing a selected 
reader and/or smart card configuration file selected 
5 based upon card and/or card reader type, wherein an 
input device 350 is used to select card and/or card 
reader configuration files and to select various 
commands for formatting or otherwise communicating with 
a card and/or card reader. Operation of the E2 card 
10 formatting system and method will be explained as 
follows. 

Operation of the system and method for creating 
easily interf aceable smart cards, card readers and 
information systems, to create or format a smart card 

15 and card reader and in essence configure a variable 
software engine which communicates with the information 
system, reader and card, occurs in two phases, a setup 
phase and an operational phase. In order to configure 
a software engine of a software tool, for formatting 

20 smart card and card reader based on user specification, 
configuration files are prestored for configuring the 
software engine based upon various types of smart cards 
and card readers; a configuration file is selected and 
stored based upon a type of card or card reader to be 

25 formatted; the software tool is configured based upon 
the selected and stored configuration file; desired 
commands for formatting or otherwise communicating with 
the card or reader are selected based upon user 
specification; and a card and/or card reader are 

30 formatted based on the selected card and/or card reader 
commands . 

For every different card or card reader, there is 
the noxrmally unique set of commands, wherein each 
command includes an associated instruction. Instead of 
35 having to hardcode d sired instructions within a 
software engine, all the commands and instructions are 
stored in configuration files, including smart card 
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(CDC) configuration files and card reader (RDC) 
configuration files for various types of cards and card 
readers. Thus, if a new command is to be introduced, 
instead of having to rewrite the entire software engine, 
5 the system can add a new command and associated 
instruction configuration files so that a software 
engine can read in the information and reconfigure 
itself to work with the appropriate reader and/or card. 
The basics of the setup phase are as follows. 

10 As shown in Fig. 5, the setup phase begins at Step 

S2 . At Step S4, if desired, a reader RDC 

(configuration) file is selected using input device 3 50. 
A list of RDC files for various types of readers can be 
displayed on display 340 for example. Once selected 

15 based upon a type of reader in Step S4, the selected 
configuration file is then read into dynamic memory 330 
and stored therein in step S6. 

Thereafter, card configuration files are displayed 
for various types of smart cards. A card configuration 

20 file (CDC) for a particular type of smart card to be 
configured is selected in Step S8. The CDC file of the 
selected smart card type is then read into dynamic 
memory in Step SIO and the set up phase for setting up 
a card and card reader ends in Step S12 of Fig. 5. The 

25 open software engine of the software tool 300 is then 
configured based upon the selected RDC or CDC file to 
thereby initialize the engine for communication with the 
selected reader or card. 

Accordingly, in the setup phase, the Microsoft 

3 0 Windows library of routines that provide support for 
interfacing smart cards and readers is populated with 
information (from a configuration file) specific to a 
type of smart card or smart card reader to be formatted, 
namely the library is populated with products specific 

35 information. Thus, information specific to a type of 
smart card and card reader are selected and retrieved 
from the CDC and RDC configuration files for all types 
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of smart card and card reader products stored in memory 
32 0 (or an external memory) . The selected and stored 
configuration file contains operational parameters 
(product information, transmission protocol, error 
5 handling, command/ response processing) as well as 
details of each supported command* Further data of 
configuration files includes transmission/reception 
elements, communication protocol, potential error codes 
and messages, position in response to strings of key 

10 information, and parameters (instruction, unique errors, 
response information, etc*) for a re-supported command. 
A typical reader that can process five commands and a 
card that has 2 0 available commands, would result in 
approximately 3 00 values being read from the RDC and CDC 

15 configuration files. Reference is made to the CDC and 
RDC configuration file specification section described 
hereafter, for guidelines- In short, a configuration 
file lists in text format, all the data necessary for 
the component to communicate and operate with the 

20 product. Thus, based upon the selected and stored CDC 
or RDC configuration file, the engine of the software 
tool can be configured for formatting or otherwise 
communicating with a card or card reader. 

At the beginning of the setup phase in Step S2, the 

25 Delphi component as the open software engine is added to 
the application (the configuration of a system for 
formatting or communicating with a type of smart card 
and card reader based on user specification) that is 
being developed. Next, RDC and CDC files are selected 

3 0 that match the products (type of card and reader) to be 
used by the application in Steps S4 and S8. After 
retrieving the infojrmation from the appropriate RDC and 
CDC files, and storing these selected configuration 
files in dynamic memory 330 in Steps S6 and SIO, the 

35 engine of the software tool is configured and is ready 
to control product operation. 
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The operational phase begins at Step S2 0 as shown 
in Fig. 6a. This is the phase where a user can select 
from the plurality of prestored configuration files for 
a card or card reader, and can configure or reconfigure 
5 the software engine to desired specifications. During 
the operational phase, coitimands are asseinbled and 
executed in real time. Further, all Microsoft Windows 
messaging, including external port activation, response 
routing and error handling, are easily processed. 

10 In the setup phase, one of a plurality of prestored 

reader configuration and card configuration files are 
selected based upon a type of reader and/or card to be 
formatted or otherwise communicated with, wherein the 
selected file is stored in dynamic memory 330 of the 

15 software tool 3 00. During the operational phase 
process, at least one desired card and/or reader command 
is selected. The at least one selected card and/or 
reader command is then formatted and stored in memory of 
the respective card and/ or card reader, namely in memory 

20 220 and/or 120 as shown in Figs. 3 and 2, respectively. 
The card and/or card reader can then be formatted or 
reprogrammed based upon the files stored in memory 
therein. 

More specifically, once the operational phase 
25 begins in Step S20, the system proceeds to Step S22 
wherein a command string is constructed. A command 
string denotes user specification of a CDC or RDC file. 
A single command line can be used within an application 
code to instruct the component to process and send the 
30 command, as well as handle any response information. 
The component accepts an English-like command with 
associated parameters and converts it into an 
instruction having a series of numeric valves, for 
example, hex values for transmission to the reader. For 
35 example, in Step S22, the command string: 

TSmTool.ExecuteCommand( [cmdname, parameter list] ) ; 
wherein "cmdnaune" is the command to be executed and 
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"parameter list" is the comma separated information 
required to correctly process the command. The process 
then proceeds to Step S24 of Fig. 6a. 

In Step S24 of Fig. 6a, the constructed command 
5 string is compared to commands from the RDC file 
selected during the setup phase based upon the type of 
reader to be formatted, and stored in dynamic memory 
330. In Step S26, it is thereafter determined whether 
or not the constructed command string, which is used to 
10 select at least one of the card reader files, matches 
the commands of the RDC file selected during the setup 
phase and stored in dynamic memory 330. If not, then in 
Step S28, the command string constructed in Step S22 is 
compared to commands from the CDC file selected during 
15 the setup phase. The configuration file is selected 
based upon the type of card to be formatted and is also 
stored in dynamic memory 330. In Step S30, it is 
determined whether or not the constructed command string 
matches the commands of the CDC file stored in dynamic 
20 memory 330 based upon the type of card to be formatted 
to determine whether or not the constructed command 
string is being used to select at least one card 
command. If not, then in Step S32, the command is not 
recognized and in Step S34, the process is returned to 
25 await a new command string. 

If the command string of Step S22 does match either 
a command in a stored RDC file in Step S26 or a command 
in a stored CDC file in Step S3 0, then the command can 
be formatted in Step S3 6 of Fig. 6a. More specifically, 
30 tag command information that correspond to the match 
found in Step S26 or Step S30 is determined such as 
instruction information, unique error information, 
response time/length information, etc. Then, every 
character of the instruction tag is looped through. 
35 Place holders are substituted with actual values from 
the parameter list. Those place holder names that begin 
with the letter "X" are entered as literal hex values. 
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and those numbers that begin with "Z" are translated to 
ASCII equivalents. Thereafter, other command formatting 
procedures are stepped through as determined by 
appropriate sections in the reader and/or card 
5 configuration file. Preface information is then added 
to the command including: reader/card NAD and length 
byte(s) . If appropriate, an EOT byte is added. 

Thereafter, reader additions for card IN/OUT types 
commands, as determined by the stored configuration 

10 file, are added. If required, transport layer protocol 
(TLP) is added as required. TLP converts each byte into 
two ASCII characters to prevent equipment from 
interpreting any control characters. Finally, an 
appropriate epilogue is calculated-error byte(s). This 

15 is typically the bitwise XOR calculation as defined by 
EDC type parameters in the reader RDC configuration 
file. This error byte is often added to the end of the 
command string and used for transmission verification. 
The transmitting and receiving of the command will now 

2 0 be described as follows with regard to Fig. 6b. 

Once a command has been formatted in Step S3 6, the 
formatted command is then transmitted to the reader (or 
card) in Step S38. A wait stage is entered in Step S40. 
In Step S42, the communication port buffer of the 
25 software tool (workstation) 300 is continuously polled 
for a response from the reader (or card). In Step S44, 
it is determined whether or not a predetermined response 
time has lapsed without feedback from the reader (or 
card) ♦ If the response time has lapsed, error checking 

3 0 for time-out occurs and the system proceeds back to Step 

S38. If the time has not lapsed and a response has been 
received, then in Step S46 a response from the reader 
(or card) is extracted from the communication port 
buffer. Data is then preprocessed (EX. reverse TLP if 
3 5 appropriate) to get ready for the response analysis. 
Any communication port errors are deciphered and the 
process proceeds to Fig. 6c. 
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In Pig. 6c, the process for handling the response 
is described. Initially, in Step S48, the response is 
checked. Specifically, post NAD and EDC are verified to 
determine that they are correct. An incorrect match 
5 could indicate a transmission problem. If a problem 
occurs, an attempt is made to request that the reader 
resend the response. 

In Step S50, the system looks for a reader return 
code (RC) . The location of this byte(s) is defined by 

10 the reader configuration file (RDC) . If an error 
occurs, then the RC is matched with common reader 
errors. If no match occurs, and the command is a reader 
level command, then the process continues to check for 
unique errors. The reader RC is located, or not, in 

15 Step S52. 

If the reader RC is not located in Step S52, then 
the system moves to look for a card command and then 
continues to evaluate a response for card processing 
information. Specifically, a card RC (return code) is 

20 looked for in Step S54 . If the card RC is not okay, 
then it is compared against common card errors and 
errors that might be unic[ue to the command that has been 
issued* The card RC is located, or not, in Step S56. 

If a card RC is located in Step S56, then the 

25 system moves to Step S58 wherein response data is 
obtained. If a card command has been issued, then 
response data must be obtained. For example, if the 
card command that had been issued was to read the first 
file in the card, then the response data segment would 

3 0 be the contents of file one. This also requires that 
the response be converted ASCII. 

Thereafter, if a reader RC or card RC was located, 
the command is processed in Step S60. The commands are 
stored in the appropriate memory 120 or 220 of the card 

35 reader 100 or smart card 200 and are used to format the 
card reader or smart card. Of one final note is that 
during the processing step in Step S60, the properties 



W0 9fir/S23? PCT/US9T/22429 

17 

RtnData, RtnCode, RtnStatus, RtnSent are populated with 
the status information to allow the application to check 
if a command was processed, and how it was processed. 
Thereby, the reader or card are formatted, 
5 During the operational phase, a single command line 

can be used within an application code to instruct the 
component to process and send a command, as well as 
handle any response information. The component accepts 
an English-like coinmand with associate parameters and 
10 converts it to a series of hex values for transmission 
to a reader. The following example is as follows: 

Using the component , namely software tool 3 00, a 
software developer could write the following line to 
verify if the first secret code stored on a smart code 
15 is in fact the word "test code": ExecuteCommand 
[ (CrdPresentCode, "1" , "test code") ] . 

If the aforementioned instruction was intended for 
one particular card being read by a specific reader, the 
component would automatically translate the command and 
20 send a series of hex bytes to the card reader through a 
communications port of the software tool 300 as follows: 
[65 OD 00 20 00 01 08 74 65 73 74 63 6F 64 65 5B] . The 
component translates the response [56 04 00 2 0 98 04 EE] 
to miean "incorrect secret code", which is then returned 
25 to the application of the developer. 

Now, assuming that during the setup phase, an RDC 
configuration file and a CDC configuration file were 
instead loaded for another reader and card, 
respectively. To perform the same function, the series 
3 0 of bytes sent to the reader would be, for example: [36 
30 30 45 31 34 30 30 34 32 30 30 30 31 30 38 37 34 36 35 
37 33 37 34 36 33 36 46 36 34 36 35 32 41 03]. The 
response bytes received from the reader would then 
prompt the component to reapply with the "incorrect 
35 secret code" status. 

It should be noted that this software code remains 
exactly the same and an identical response is generated 
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even though a different reader and card are used. The 
software developer does not need to be concerned with 
the complexities of how these commands are assembled. 

From an application user perspective, it should be 
5 noted that how a product that is built on the card 
methodology, for example, an EZ card methodology, would 
appear to an end user is dependent on the type of 
application. Frequently, applications built on EZ card 
methodology will perform dedicated tasks. For example, 

10 a front desk module in a hotel system would be limited 
to issuing new cards to arriving guests. It should be 
noted, that although smart cards are discussed in 
connection with the present application, other cards 
such as magnetic stripe cards, memory chip cards, and 

15 COS cards can also be used. 

Some features are common to all applications of the 
EZ card methodology. Specifically, applications would 
require the following steps at a minimum: a reader 
would have to be connected to a host software tool 3 00 

20 through a communications port; MS windows would have to 
be started; a program would have to be run; a 
configuration (set up) option to select which CDC and 
RDC files match the type of card and reader being used 
would have to take place; the reader would have to be 

25 powered on; the card would have to be powered on; and 
one or more of the reader and card functions or commands 
would have to be performed to format the card and 
reader. Examples include: create file/directory 
structures, read files, update files, authenticate 

3 0 codes, review file status, implement security 
schemes/access conditions, etc. 

Regarding the formatter operation, the software 
tool includes a formatter, herein referred to as an EZ 
formatter, that is a typical utility program built on 

35 the EZ card methodology. It provides an easy way to 
interact with readers and cards. The EZ formatter can 
be used: 1) to format blank cards; 2) to personalize 
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cards; 3) in training; 4) in front end to demo systems; 
5) to verify card authenticity; and 6) to test card 
security schemes, for example. A tool status bar at the 
top of the screen provides global function (example 
5 reset card and reader) and status information (example 
active directory/file) . The application has five screen 
pages that can be selected via notebook tabs. Each page 
represents a different grouping of functions. 

A first type of page is a configuration page. This 

10 page is used to set RDC and CDC reader and card 
configuration files to be used (based upon card/card 
reader type) . It also selects the type of communication 
between the reader and host work station (such as a 
serial port number, parallel port, PCMCIA, etc.). A 

15 second type of page is a security page. All secret 
codes are created and verified here. Codes can also be 
changed or unblocked as appropriate. Directory/ file 
status and access conditions can be reviewed. 

Template pages are a third type of page which 

20 define and create directory/ file structures on smart 
cards. Structures can be saved to disk and retrieved 
for the future. When creating a new file or directory, 
the user is prompted for a file type, length, address, 
and access conditions. Files can also be deleted. A 

25 card viewer page is another type of page wherein the 
card viewer page is used to write and to read from 
selected files. The card viewer page can be used to 
dump the contents of an entire card. Finally, a 
writable area page can be used, however this page is 

30 relevant only from memory cards. The page shows a 
visual map of the card-to-memory addresses including 
which cards have been written and which cards are still 
unused. 



35 



CDC and RDC Configuration File Sp cifications 

This section describes the structure and allowable 
formats for configuration fil s (referred to as CDC and 
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RDC files) that are compatible with the preferred 
embodiments of the invention; 

The CDC an RDC files are formatted similar to MS 
Windows in files. A unique CDC and RDC file is required 
5 for every card and reader type that is to be used. 
File Structure 

The general format follows the Windows in 
structure. Section headings are in brackets. Under 
each section parameter, names are listed (one per line) 
10 followed immediately by an equals sign and the 
associated data value. For example: 

• [Section Heading] 

• Parameterl=Valuel 

• Parameter2=Value2 



• tSection2 Heading] 

• Pa r ame t er X=Va lueX 
20 • .... 

All CDC and RDC files contain the following required six 
sections: 

• AUTHOR 
PRODUCT 

25 • COMMUNICATION PROTOCOL 

• TRANSMISSION 

• RECEIVE 

• COMMANDS 

Additional sections may then follow, such as one 
3 0 for each command listed in the COMMANDS section. For 
example, a reader type RDC file that defines two 
commands (readeron, readeroff) in the COMMANDS section 
will have two additional sections [READERON] and 
[READEROFF] that list the respective functional 
35 inf oirmation. 

Parameter names and values must be located under 
the correct Section heading. Not all CDC and RDC files 
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will have the same parameter names. Differences between 
reader and cards are represented by variations within 
the CDC and RDC files. To be understood correctly by 
the EZ Card System, data values must conform to the 
5 defined standards (See Contents and Descriptions) . 
Contents and Descriptions 

Product Type defines the parameters as valid for a 
reader, card, or both. 

Allowable Values are typically one of the following: 
10 (1) Integer: Positive whole numbers (up to 4 

digits) 

(2) String: Collection of characters not to 
exceed length of 255 

(3) Specific: Exact entries are shown in italics 
15 (4) Hex: Two digit hex values. When there is 

more than one, the members of the series should be 
separated by a single space. For example: RC 
Success=90 00 

(5) Err Format: hex, comma, space, error 

20 description. For example: 

Common Error 1=9 2 00, Write Problem in EEPROM 
Common Error2=98 04, Required secret code not 

presented. 

Description explains how the values are interpreted by 
25 EZ Card System. 

Author: This section identifies the source and/or 
author of the CDC and RDC file. 
Creation Date 

Product Type: All 
30 Allowable Values: string 

Description: Date of CDC and/or RDC file. 
Company 

Product Type: All 
Allowable Values: string 
35 Description: Name of company which created CDC 

and/or RDC file. 
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Individual 

Product Type: All 
Allowable Values: string 

Description: Name of individual which created CDC 
5 and/ or RDC file. 

Comment 

Product Type: All 
Allowable Values: string 

Description : Additional information ( ex . 

10 Phone/ email of individual) 

Product This section identifies the product to which 

the CDC and/or RDC file pertains. 

Name 

Product Type: All 
15 . Allowable Values: string 

Description: Brand name of product 
Manufacturer 

Product type: Both 

Allowable Values: string 
20 . Description: Name of Manufacturer of product 

for which the CDC and/or RDC files have been 

configured . 

Type 

Product Type: Both 
25 . Allowable Values: 1, 2, 3 

Description: Identifies the CDC and/or RDC 
file as that for a: 
reader - l 
smart card - 2 or 
3 0 PCMCIA card - 3 (future) 

Communication Protocol: This section contains parameter 
information needed to initiate a communication link to 
the host. A Serial RS232 port interface can be used for 
readers. Alternatives include PCMCIAN, parallel, and 
35 keyboard port inter fac s. 
R ad r Type 

Product Type: Reader Only 
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Parity 



10 



Databits 



15 



Stopbits 



20 



23 

Allowable Values: PCMCIA, SERIAL, PASSTHRU 
Description: Define the reader to be used* 

Product Type: Reader Only 

Allowable Values: 9600, 14400, 19200, 38400 
Description: Defines the speed at which the 
reader will operate. 

Product Type: Reader Only 

Allowable Values: even, odd, none, mark, 
space 

Description: Defines the parity bit for 
reader communication. 

Product Type: Reader Only 
Allowable Values: 7, 8 

Description: Defines the data bit for reader 
communication . 



Product Type: Reader Only 
Allowable Values: 0, 1, 2 
Description: Define the 
reader communication. 



stop bit (s) for 



Card Type 



25 



30 



35 



Product Type: Smart Card Only 
Allowable Values: COS, MEM, MAG 
Description: Identifies the card as a: 
Chip Card with Card Operating System - COS 
Memory card - MEM 
Magnetic stripe card - MAG 
Memory Area 

Product Type: Smart Card Only 

Allowable Values: SFN, CAF, parameterized 

range, or integer 

Description 

1. For MEM cards, the writable area is given 
as a parameterized range. Start address 
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and length of area, repeat as necessary 
with pairs separated by commas • For 
example: a memory card that has two 
writable areas... the first from byte 1 
5 to byte 50, the second from byte 75 to 

100 would be as follows: Memory Area=l 
49, 75 24 

2. For MAG cards this integer value will 
list how many tracks the card supports. 
10 3 . For COS cards this identifies how new 

files are created 

System assigns File Names - SFN or 
Card Allocates Files -CAF 
Transmission This section defines how command strings 
15 are constructed and transmitted to the reader/card. 
Information includes command composition, address 
identifiers, and error detection techniques. 
Reader NAD 

Product Type: Reader Only 
20 . Allowable Values: Hex 

Description: Node address of the reader 

Card NAD 

Product Type: Reader Only 
Allowable Values: Hex 
25 . Description: Node address of the card. Used 

to direct commands through the reader to the 
card. 

EDC Type 

Product Type: Reader Only 
3 0 . Allowable Values: 1, 2, 3, 4 

Description: identifies how much of command 
string should be XOR in order to arrive at 
correct error byte: 

entire string - 1 
3 5 ignores NAD - 2 

ignores EOT - 3 
ignore both NAD & EOT - 4 
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Two Pass ACK 

Product Type: Selected Readers 
Allowable value: Hex 

Description: Acknowledgement hex value 

5 returned by those readers that send ACK prior 

to processing conmiand (2 pass protocol) . 

EOT Flag 

Product Type: Selected Readers 
Allowable value: Hex 
10 . Description: End of Transmission code that is 

added to command string • 
Composition Type 

Product Type: All (currently used for Readers 
only) 

15 . Allowable Values: O, TLP, TLPl, PCSC 

Description: identifies format which command 
strings : 
Normal - 0 

Transport Layer Protocol. Each byte is 
20 transmitted into two ASCII characters - TLP 

Process data only - TIiPl 
Card Command In 

Product Type: Selected Readers 

Allowable Values: Hex 
25 • Description: Code that must preface card 

levels commands that send data to the card. 
Card Command Out 

Product Type: Selected Readers 

Allowable Values: Hex 
30 . Description: Code that must preface card 

level commands that retrieve data from the 

card and send it out to the host. 
Card Command Tl 

Product Type: Selected Reader 
35 ' Allowable Values: Hex 

Description: Code that prefaces T=l commands 
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L ngth Byt s 

Product Type: All 
Allowable Values: 0, 1, 2 

Description: identifies how many bytes are 
5 used for sending length byte. If 0 then 

product does not require a length byte. 
Receive This section defines the structure of response 

as they are received back to the host. 
Response NAD 
10 . Product Type: Reader Only 

Allowable Values: Hex 

Description: Node address of response (host 
terminal) 
RC Reader Iiocation 
15 . Product Type: Reader Only 

Value: Integer 

Description: Byte number after the NAD where 
the reader return code (RC) begins. For 
example, if the response for reader level 

20 commands is: NAD+LEN+RC+data+EDC , then the RC 

Reader Location would be 2. 
RC Card Location 

Product Type: Reader Only 
Value: Integer or END 

25 . Description: Byte number after the NAD where 

the card level return code begins. If the RC 
is always at the end of the response then this 
value should be "END". 

RC Success 
30 . Product Type: All 

Allowable Values: Hex - multiple allowable 
success codes are separated by command and a 
space. Example: RC Success=90 00, 60 90 

Description: The return code(s) that indicate 
35 a successful execution of a command. 
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CommonError* where * equals a sequentially increasing 
integer up to number of Errors to be listed. 

Product Type: All 

Allowable Values: ErrFormat 
5 . Description: List of return codes and 

associated error messages. 
Commands This section lists the possible commands. 
Command* where* equals sequentially increasing integers 

up to number of commands to be listed. 
10 . Product Type: All 

Value: String 

Description: These values are the command 
identifier names that will appear as CDC and 
RDC file section headings in the remaining 
15 sections of file. 

Example: 

Commandl=CrdPresentCode 
Command2=CrdReadFile 
Two additional sections [CrdPresentCode] and 
20 [CrdReadFile] must be established to hold the command 
details. 

While the coinmands can be completely customized by 
the CDC and RDC file author, a suggested convention is 
to include the following commands at a minimum. 
25 For Reader RDC file: RdrReset^RdrOf f ,RdrStatus. 

For Card CDC file: CrdPresentCode, CrdCreateFile, 

CrdReadFile, CrdWriteFile , 
CrdStatus. 

[Command Identifier] Each command listed in the 
30 Commands Section will have its own separate section to 
describe the details of the command (instruction, 
errors, response time/length) 
Type 

Product Type: All 
35 . Allowable Values: 0, 1, 2, 3 

Description: Defines command exchange 
0 - normal exchange of bytes 
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3 



2 



1 



reader command controlled by serial 
line 

single byte at a time 
chained command 



Instruction 



10 



15 



20 



25 



30 



Product Type: All 

Allowable Values: Hex/ Special 

Description: Actual sequence of bytes that 
formulate the command. The Instruction is the 
sequence of hexadecimal bytes that is sent to 
the reader/card. In many instances the 
Instruction will contain placeholders for 
additional information that must be added by 
the application for the command to be 
correctly constructed. For example, consider 
the command named "CrdPresentCode. " The 
Gemplus COS card representation is: 

lnstruction=00 20 00 xnum 08 zcode 



where xnum represents the number of the secret code to 
be presented and zcode represents the actual code. 
Placeholders prefaced with the letter "x" pass their 
value as a hex. Placeholders prefaced with the letter 
"2" pass their actual character value. When the above 
instruction is called from an EZ Card System application 
with the additional parameters "1" and "usercode", the 
component appends the hex representation of bytes to 
read : 

00 20 00 01 08 75 73 65 72 63 6F 64 65 
Response Time 

Product Type: All 
Allowable Values: Integer 

Description: Time in milliseconds that host 
should wait for response. After the elapsed 
time, host will consider that an error has 
occurred and return a time-out. 
Response L ngth 

Product Type: All 
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Allowable Values: Integer or Open 
Description: Expected length of response data 
to be received by host* This is in addition 
to the normal return codes and error checks. 
5 Many coimaands like writing to a file and 

turning off a reader producing no response 
(i.e. Response Length=0) . Commands lacking a 
predetermined response, for example, reading 
a file, will have a Response Length = Open 

10 Error* where * equals sequentially increasing 

integers up to number of unique errors for 
this command (max 8) 
Product Type: All 
Allowable Values: ErrFormat 

15 . Description: Possible errors, unique to this 

specific command, that may be encountered 
during execution. Up to eight separate unique 
errors can be stored for each command. 

Comment 

20 . Product Type: All 

Allowable Values: string 

Description: Store hint regarding 

implementation of the command. Not actively 
used by EZ Card System. 

25 Figure 7 illustrates an interfacing architecture 

that includes the software tool described above. The 
application Programming Interface (API) 400 or accessing 
methodology kernel, includes higher level card 
functions, such as a series of Dynamic Link Libraries 

30 (DLLs) that may be called from products, software 
applications or solutions developed by outside users. 
This accessing methodology, which calls on any of the 
appended library modules to process commands, includes 
but is not limited to methods to format and write data 

35 manage card and reader properties, control the 
registration and operation of add-in modules, instruct 
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and transmit commands, and receive and interpret card 
return codes. 

The accessing methodology manages all interfacing 
with readers and cards. This includes constructing the 
5 commands that are to be directed to the card. Commands 
are converted to a data stream of hexadecimal bytes that 
are typically transmitted out the computer's 
communication port, like the RS232, to an attached 
reader and then forwarded on to the card. The card will 

10 then generate a reply and pass these response 
hexadecimal bytes back up to the computer or host. Also 
included in the accessing methodology are the 
interpretation of response codes, MS Windows system 
messaging, and reader/card error and exception handling. 

15 The invention being thus described, it will be 

obvious that the same may be varied in many ways. Such 
variations are not to be regarded as a departure from 
the spirit and scope of the invention, and all such 
modifications as would be obvious to one skilled in the 

20 art are intended to be included within the scope of the 
following claims. 
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What is Claimed is; 

1 !• A method for communicating with a card and a card 

2 reader, comprising the steps of: 

3 prestoring a plurality of files for configuring a 

4 software tool to communicate with the card as a 

5 plurality of card configuration files; 

6 prestoring a plurality of files for configuring the 

7 software tool to coxnmunicate with the card reader as a 

8 plurality of reader configuration files; 

9 selecting one of the card configuration files; 

10 selecting one of the reader configuration files; 

11 storing the selected card configuration file and 

12 reader configuration file; and 

13 configuring the software tool for communicating 

14 with the card and card reader based upon the respective 

15 stored selected card and card reader configuration 

16 files, 

1 2. The method of claim 1, further comprising the steps 

2 of: 

3 selecting another one of the card 

4 configuration files; 

5 storing the another card configuration file in 

6 place of the stored card configuration file; and 

7 reconfiguring the software tool for 

8 communicating with another card based upon the stored 

9 another card configuration file. 
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1 3 . The method of claim 2 , wherein the cards are smart 

2 cards • 



1 4. The method of claim 1, further comprising the steps 

2 of: 

3 selecting another of the reader configuration 

4 files; 

5 storing the another reader configuration file 

6 in place of the stored reader configuration file; and 

7 reconfiguring the software tool for 

8 communicating with another card reader based upon the 

9 stored another reader configuration file. 

1 5. The method of claim 1, wherein the card is a smart 

2 card . 

1 6, The method of claim 1, further comprising the steps 

2 of: 

3 selecting at least one first command based 

4 upon the card configuration file; 

5 selecting at least one second command based 

6 upon the reader configuration file; 

7 formatting the card based upon the at least 

8 one first command; and 

9 formatting the card reader based upon the at 
10 least one second command. 

1 7. The method of claim 6, further comprising the steps 

2 of: 

3 formatting and storing the at least one first 

4 command ; and 

5 formatting and storing the at least one second 

6 command • 

1 8. The method of claim 7, wherein the at least one 

2 formatted first command is stored on a card memory and 
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3 the at least one formatted second command is stored on 

4 a card reader memory. 



1 9. A method for communicating with a card system, 

2 comprising the steps of: 

3 prestoring a plurality of files for 

4 configuring a software tool for communicating with the 

5 card system; 

6 selecting one of the prestored files; 

7 storing the selected file; and 

8 configuring the software tool for 

9 communicating with the card system based upon the stored 
10 file. 



1 10. The method of claim 9, wherein the card system 

2 includes at least one of a card and a card reader. 



1 11. The method of claim 9, further comprising the step 

2 of: 

3 selecting at least one command based upon the 

4 stored file; and 

5 formatting the card system based upon the 

6 selected at least one command. 



1 12. The method of claim 11, further comprising 

2 formatting and storing the at least one command. 

1 13 . The method of claim 12 , wherein the formatted at 

2 least one command is stored in memory on the card 

3 system. 

1 14. A software tool for communicating with a card 

2 system, comprising: 

3 first memory means for prestoring a plurality of 

4 card system configuration files for configuring the 

5 software tool for communicating with the card syst m; 
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6 selection means for selecting one of the prestored 

7 card system configuration files based upon a card system 

8 type ; 

9 second memory means for storing the selected card 

10 system configuration file in a dynamic memoiry; and 

11 formatting means for configuring the software tool 

12 for communicating with the card system based upon the 

13 stored card system configuration file. 

1 15. The software tool of claim 14, further comprising: 

2 input means for selecting a command for 

3 formatting the card system; 

4 card system memory means for storing the 

5 selected command in the card system; and 

6 processing means for formatting the card 

7 system based upon the selected stored command. 



1 16. The software tool of claim 14, wherein the card 

2 system includes at least one of a card and a card 

3 reader. 



1 17. The software tool of claim 14, further comprising 

2 subsequent selection means for selecting 

3 another of the card system configuration files; 

4 subsequent storage means for storing the 

5 another card system configuration file in place of the 

6 stored card system configuration file; and 

7 reconfiguration means for reconfiguring the 

8 software tool for communicating with another card system 

9 based upon the stored another card system configuration 
10 file. 

1 18. A software tool for formatting a card and a card 

2 reader, comprising: 

3 a first memory for prestoring a plurality of card 

4 configuration files and a plurality of card reader 
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configuration files for configuring the software tool to 
communicate with the card and the card reader; 

selection means for selecting one of the plurality 
of prestored card configuration files and card reader 
configuration files based upon a respective card and 
card reader type; 

a dynamic memory for storing the selected card and 
card reader configuration files, wherein the software 
tool is configured based on at least one of the stored 
card and card reader configuration files, the selection 
means further selecting a command for formatting at 
least one of the card and card reader; 

at least one of a card memory and ia card reader 
memory that stores the selected command in the 
respective card and card reader; and 

processing means for formatting at least one of the 
card and card reader based on the respective selected 
and stored command. 

19- A software tool for formatting a card system, 
comprising: 

a first memory that pr est ores a plurality of card 
system configuration files for configuring a software 
tool for formatting the card system; 

an input device that selects one of the prestored 
card system configuration files based upon a card system 
type and that selects a command for formatting the card 
system ; 

a dynamic memory that stores the selected card 
system configuration file, wherein the software tool is 
configured based upon the stored card system 
configuration file; 

a card system memory that stores the selected 
command in the card system; and 

a processing device that formats the card based 
upon the sel cted stored command. 
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1 20, The software tool of claim 19 wherein the card 

2 system includes at least one of a card and a card 

3 reader . 



1 21. A system for managing a communication with a card 

2 system , comprising : 

3 a software tool that communicates with a card 

4 system^ the software tool including 

5 a first memory that prestores a plurality of card 

6 system configuration files for configuring a software 

7 tool for formatting the card system, 

8 an input device that selects one of the prestored 

9 card system configuration files based upon a card system 

10 type and that selects a command for formatting the card 

11 system, 

12 a dynamic memory that stores the selected card 

13 system configuration file, wherein the software tool is 

14 configured based upon the stored card system 

15 configuration file, 

16 a card system memory that stores the selected 

17 command in the card system, and 

18 a processing device that formats the card based 

19 upon the selected stored command; and 

2 0 an accessing kernel that controls the communication 

21 between the software tool and the card system. 



BNSDOCtD: <WO 9825239A1 J_> 



PC17lIS97Zr242» 



1/9 



Smart Card 




Smart Card 
Reader 



100 



200 



Software Tool 



/ 300 



Figure 1 



BNSDOCID: <WO 9825239A1 J_> 



SUBSTITUTE SHEET (RULE 26) 



W0 9S/2S2» 



PCT/IISW7224» 




BNSDOCID: <WO 9825239(A1 J_> 



SUBSTITUTE SHEET (RULE 26) 



PCT/US97?22«9- 




BNSDOCID: <WO 9a25239A1J_> 



SUBSTITUTE SHEET (RULE 26) 



W09SCZ5Z39 



4/9 



PCI7US97/2X«» 



o 
o 




SUBSTITUTE SHEET (RULE 26) 

3NSDOCID: <WO 9825239A1_L> 



5/9 



Begin Setup Phase 



S2 



Select reader (rdc file) 



S4 



Read file into dynamic 
memory 



86 



Select card (cdc file) 



S8 



Read file into dynamic 
memory 



810 




S12 



Figure 5 



SUBSTITUTE SHEET (RULE 26) 



BNSOOCID: <WO ^982S239A1J_> 



6/9 



Begin Operational Phase ) S20 



Construct Command 
String 



S22 



Compare command 
to commands from 
rdc files selected 
during setup phase 
for reader 



S24 




yes- 



no 



Compare command 
to commands from 
cdc files selected 
during setup phase 
for card 



S28 




Command not 
recognized 



S36 



Retum 



Fioiire 



SUBSTITUTE SHEET (RULE 26) 



g82S239A1_l_> 



wo 98/252» 



7/9 



PCT/USr97/22429 



From flQUfo 6a 













S38 


Transmit formatted 




command to reader 


< 




S40 



PoK reader for response 



yes 



S42 




no 



Extract response from 
reader 




Figure 6b 



SUBSTITUTE SHEET (RULE 26) 



BNSOOCID: <WO 9825239A1_I_> 



wo 98/25235r 



8/9 



PCT/US9772Z«» 



from fiQuro 6b 



no 



Check response 



S48 



Look for reader rc 



S50 




look for card rc 



S54 




S56 



yes 



Gel resoonse data 



S58 



Process 



S60 



Figure 6c 



end 



SG2 



9825239A1_I_> 



SUBSTITUTE SHEET (RULE 26) 



wo 98725239 



9/9 



Ftn7DS97/22429 




SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO 9825239A1J_> 



INTERNATIONAL SEARCH REPORT 



! national Application No 

PCT/US 97/22^29 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 6 G07F7/10 G06K7/00 



According to Intemattonal Patent Clasaincation(IPC) or to both national classKlcatlon and iPC 



B. FIELDS SEARCHED 



Minimum documantation searched (classitlcation system followed by classification symbols) 

IPC 6 G07F G06K 



Documentation searched other than mtnlmumdocumentation to the extent that such documents are included In tlie fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category * Citation of docuntent, with Indication, where approprtalet of the relevant passages 



Relevant to claim No. 



p. A 



WO 96 19771 A (EUROTRONICS COMPANY) 27 
June 1996 

see the whole document 



WO 96 36051 A (SMARTMOVE NZ LIMITED 

;ZUPPICICH ALAN NOEL (NZ)) 14 November 
1996 

see page 2, line 13 - page 6, line 14 

DE 195 36 548 A (IBM) 3 April 1997 

see page 4,. line 54 - page 7, line 53; 
figures 1-6 



I- 5,9,10 

6-8, 

II- 21 

1-21 



1-21 



□ 



Further documents are listed in the continuation of box C. 



Patent family members are listed in annex. 



" Special categories of cited documents : 

A" document defining the general state of the art which is not 

considered to be of particular relevance 
'E" earlier document but published on or after the international 
filing date 

L* document which may throw doubts on priority clalm(s) or 
which Is cited to establish the publication date of another 
citation or other special reason (as specified) 

''O" document refoning to an oral disclosure, use. exhibition or 
other means 

P" document published prior to the international filing date but 
later than the priority date claimed 



'T' later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an Inventive step when the document Is taken alone 

"Y" document of particular relevance: the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

document member of the same patent family 



Date of the actual completion of thainternational search 



17 April 1998 



Dale of mailing of the international search report 

24/04/1998 



Name and mailing address of the ISA 

European Patent Office. P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 



Authorized officer 



Degraeve, A 



Forni PCT/lSA/210 (second sheet) (July 1992) 



BNSDOCID: <WO 9825239A1J_> 



INTERNATIONAL SEARCH REPORT 

Information on patent family members 



Ir lational Appttcation No 

PCT/US 97/22^ 



Patent document 
cited in search report 



Publication 
date 



Patent family 
member(s) 



Publication 
date 



WO 9619771 A 



27-06-96 



US 5636357 A 
AU 4644196 A 



03-06-97 
10-07-96 



UO 9636051 A 



DE 19536548 A 



14-11-96 



03-04-97 



AU 687312 B 
AU 5517996 A 
EP 0826215 A 



US 5684742 A 



19-02-98 
29-11-96 
04-03-98 



04-11-97 



Form PCT/ISA/210 (palenl family annex) (July 1992) 
BNSDOCID: <WO 982S239A1J_> 



J 



II 




